Generally, the present invention relates to monitoring data messages in a communications network. One preferred application environment for the invention is a network element in an intelligent network, such as a SCP network element, but the solution in accordance with the invention can be used in any network elements where messages of a given protocol level are to be monitored in order, for example, to verify their validity. In the following, the invention will be described using an intelligent network as an example because the invention was created largely in response to the problems associated with intelligent networks.
With the rapid advancement of the telecommunications field, operators are now in a position to offer users a wide range of services. A network architecture providing advanced services is known as an Intelligent Network, commonly referred to as IN.
The functional architecture of the intelligent network is illustrated in FIG. 1 where the functional entities of the networks are shown as ovals. A brief description of this architecture is given below because the invention is later explained with reference to the intelligent network environment.
Access of the end-user (subscriber) to the network is controlled by the CCAF function (Call Control Agent Function). Access to IN services is provided by making additions to the existing digital exchanges. This is achieved by making use of the Basic Call State Model BCSM that describe,s the existing functionality used for processing a call between users. BCSM is a high-level state automation model for the CCF call control functions required for setting up and maintaining the connection path between the users. Functionality is added to this state model by using the Service Switching Function SSF (cf. the partial overlapping of the functional entities CCF and SSF in FIG. 1) to make it possible to decide when intelligent network services (IN services) should be invoked. Once these IN services have been invoked, the Service Control Function SCF that incorporates the service logic for the intelligent network handles service-dependent processing (of the call attempt). Thus, the Service Switching Function SSF links the Call Control Function CCF to the Service Control Function SCF and allows the SCF function to control the Call Control Function CCF. For example, SCF may request SSF/CCF to perform certain call or set-up functions, such as billing or routing operations. SCF may also send requests to the Service Data Function SDF that controls access to intelligent network service-dependent information and network data. For example, SCF may ask SDF to retrieve data related to a certain service or to update such data.
The functions described above are further complemented by the specialized resources function SRF which provides the special functions required for implementing some of the services provided by the intelligent network. Examples of such services are protocol conversions, speech recognition, voice mail, etc. For example, SCF may request the SSF/CCF functions first to set up a connection between the end-users and SRF and then ask SRF to play announcements to end-users.
Other functional entities in an intelligent network are the various control-related functions such as the Service Creation Environment Function SCEF, the Service Management Function SMF, and the Service Management Access Function SMAF. SMF includes, among other things, service control, while SMAF offers an interface to SMF and SCEF makes it possible to define, develop, test and feed the IN services to SCF through SMF. Because these functions are solely related to the network operator functions, they are not shown in FIG. 1.
The role of the functional entities shown in FIG. 1 with regard to IN services is briefly explained below. CCAF receives the service request from the calling party that typically consist of lifting the receiver and/or a specific series of digits dialed by the calling party. CCAF forwards the service request to CCF/SSF for further processing. The Call Control Function CCF has no service data but it is programmed to recognize the need for a service request. CCF momentarily suspends the call set-up process to indicate the state of the call to the Service Switching Function SSF. SSF""s tasks is, then, using a set of predefined criteria, to interpret the service request and so determine whether it relates to services provided by the intelligent network. If so, SSF will generate a standardized IN service request and send it, together with the information on the state of the service request, to SCF. SCF receives the request and decodes it. After this, it will cooperate with SSF/CCF, SRF, and SDF to provide the requested service to the end-user.
The physical-level architecture of an intelligent network indicates how the functional entities described above are distributed among the physical entities of the network. The physical architecture of an intelligent network is illustrated in FIG. 2 where the physical entities are shown as rectangles or circles and the functional entities as ovals. Signaling connections are represented by dashed lines and the actual transport, such as speech, by solid lines. Optional functional entities are denoted by dashed lines. The signaling network shown in the figure is a SS7 network (SS7, Signaling System Number 7, is a known signaling system that is described in CCITT""s (currently ITU-T) blue book Specifications of Signaling System No. 7, Melbourne 1988).
Subscriber Equipment SE which can include, for example, a telephone, computer or fax machine, are connected either directly to the Service Switching Point SSP or to the Network Access Point NAP.
The Service Switching Point SSP offers the user access to the network and carries out all the necessary selection functions. SSP is also capable of recognizing requests for intelligent network services. Functionally, SSP includes the call control and service selection functions.
The Network Access Point NAP is a conventional telephone exchange, such as the applicant""s DX 220 exchange, that includes the call control function CCF and is capable of distinguishing between conventional calls and calls requesting IN services and routing the IN service calls to the appropriate SSP.
The Service Control Point SCP includes the Service Logic Programs SLP used for generating intelligent network services. For the sake of brevity, SLPs may below also be referred to as service programs.
The Service Data Point is a database that contains information on customers and the network that SCP""s service programs use to generate personalized services. SCP may use SDP""s services directly through the signaling or data network.
An Intelligent Peripheral offers special functions such as announcements and voice and multiple choice recognition.
The Service Switching and Control Point SSCP consists of SCP and SSP housed in a single network element (meaning that if the SSP network element shown in the figure includes both the SCF and SSF entities, the unit involved is a SSCP).
The tasks of the Service Management System SMP is to manage the Service Data Point SDP, control and test the network and to collect network data. SMP can connect to any other physical entity.
The Service Creation Environment Point SCEP is used for defining, developing and testing the intelligent network services and entering the services into SMP.
The Adjunct AD corresponds to the Service Control Point SCP in terms of function, but it is directly connected to the SSP using a fast data connection (such as the ISDN 30B+D connection) instead of being connected via the common channel signaling network SS No.7.
The Service Node SN is designed to control IN services and perform data transfers with users. It communicates directly with one or more SSPs.
The Service Management Access Point SMAP is a physical entity that offers access to SMP for certain users.
The SCP network element may also be accompanied by a separate assisting SCP. This type of assisting SCP network element may be operated by the service provider that maintains subscriber-specific number translation or routing logic that is offered to the network operator""s SCP network element to complement the control data existing there.
The foregoing provides a brief description of an intelligent network to serve as a background for the method in accordance with the present invention. An interested reader will find more information on intelligent networks by consulting ITU-T""s Q.121X specifications or Bellcore""s AIN specifications.
For example, the system uses the Intelligent Network Application Part INAP message set between SSP and SCP. (This message set is explained, for example, in the standard ETSI IN CS1 INAP Part 1: Protocol Specification, Draft prETS 300 374-1, November 1993, where an interested reader can find more background information). In the SS7 protocol stack, illustrated in FIG. 3, INAP is the highest layer, followed by the Transaction Capabilities Application Part TCAP, the Signaling Connection Control Point SCCP, and the Message Transfer Part MTP. Thus, the structure is layered in that a higher layer makes use of the services provided by the layer directly beneath it. The INAP layer provides the interface to IN services.
The standards do not specify the actual protocol to be used between SSP and SCP, only the INAP messages, some of which are used for transmission in one direction and some for transmission in the other direction. Fixed and optional parameters as well as xe2x80x9cextension parametersxe2x80x9d are defined for the messages. Thus, individual service logic programs may use the messages contained in the same INAP message set but in different order and with different parameter values. Consequently, it is the individual service logic programs that serve as the actual protocol level in the communications between SSP and SCP. Each service logic program sends INAP messages to the network and receives INAP messages from the network.
All these INAP messages have been defined using the ASN.1 definition language. ASN.1 (Abstract Syntax Notation 1) is a description language commonly used in the telecommunications field for defining and coding data structures.
To ensure correct operation of the system, incoming and outgoing message traffic must be monitored when the network element is commissioned, if not earlier. Moreover, the operator may be interested in monitoring messages while the network element is in operation. For the SCP network element, it is particularly important to monitor INAP messages because INAP is the protocol that provides access to intelligent network services.
To make it possible for the individual responsible for monitoring to actually check the message structure, the messages must be capable of being presented in their standard format, which, in reality, is the ASN.1 format. Traditionally, this monitoring is carried out when the message of the protocol level involved is otherwise processed anyway. For example, INAP messages have conventionally been monitored in connection with service logic programs because these programs create, in the SCP network element, the xe2x80x9clocationsxe2x80x9d where the INAP messages would be processed anyway and where it is possible to access the INAP messages as such (in ASN.1 format). To put in other words, message monitoring is traditionally carried out in connection with the program blocks that would have processed the said messages anyway.
However, the drawback of this type of solution is that monitoring makes the xe2x80x9cuseful processxe2x80x9d, such as service programs, ever more complicated. Furthermore, if modifications need to be made for monitoring purposes, the changes must be made to all the service programs. This has an adverse effect on the reliability of service programs because service programs must be processed in connection with each such modification.
Alternatively, it is conceivable that the messages of the selected protocol level are monitored using lower-protocol-level messages; for example, INAP messages could be monitored already at a lower level (TCAP). However, this is often complicated. For example, the TCAP messages from the network are BER-coded (BER, Basic Encoding Rules), so that checking for the correct INAP message structure in such a bit string is extremely complicated.
The purpose of the present invention is to eliminate the said drawbacks and to provide a solution that makes it possible to efficiently monitor the messages for validity and in such a way that the implementation is simplified.
This goal is achieved by using a solution in accordance with the invention as defined in the independent patent claims.
The idea of the invention is to completely separate the functionality relating to message monitoring from the useful programs processing the message by creating, parallel to these useful program blocks, a centralized program block for monitoring the messages. This program block receives a copy of the message to be monitored, received from or sent to the network.
When using the solution in accordance with the invention, it is no longer necessary to make changes to service logic programs when the monitoring function is to be added to a network element (or similar entity), or when changes are to be made to the existing monitoring function. As a result, it is easy for a network element supplier to incorporate the monitoring functions even in the existing network elements. Since in this way useful programs (such as service programs) remain external to the actual implementation of monitoring, they will be simpler and more clear-cut in this respect, which is important to the service provider. At the same time, the reliability of service is improved.